一個人有願意創造生活，那麼他將會強壯且快樂。

這句話的意義在於，一個人必須要成為自己生活的主導，要有能力主導生活，去創造自己周遭的生活，這樣他就可以從中得到快樂，而且使得自己越來越好。我的人生一直抱持著這個信念，所以我會不停地去創造、改變我的生活，使之變得更好，這樣我也一直主導著我的生活。

回顧 Day17

在 Day17 中，我寫到我第二份公司的狀況，從一開始很固定的需求，到後來設計師放飛自我的各種設計，但那些對我來說都算還能夠完成的需求。而在後來我也逐漸得到同事跟主管的信任，我也在邊開發邊思考起到底該如何稍微優化或是加速開發這個後台產品呢？這篇，我將深入探討如何進一步優化和加速後台產品的開發。

解析並改善後台問題點

函式(function)共用性不足

問題點：
目前後台系統中存在大量相似但不完全相同的函式。這些函式經常只有微小的差異，但卻分散在不同的檔案或模組中。當需要對這些函式進行修改或更新時，必須逐一找出並手動更改，這不僅耗時也容易出錯。

解決方式：

1. 在每次需求開發過程中，將相似的函式進行整合和抽象化。
2. 將這些共用函式存放在一個專門的 utils 資料夾中。
3. 通知並告知團隊成員如何使用這些共用函式，並請他們在未來的開發中首先檢查 utils 資料夾。

結果：
我逐步建立起了不少共用函式，除了通用運算的之外，也有一些表單驗證常常會用到的客製化驗證，也被我放進共用裡，這樣就可以大幅度降低開發成本。後期也看到其他同事在用，而且如果有個類似，但他認為可以加進去的也會來找我討論。

這樣的優化不僅提升了開發效率，也促進了團隊間的協作和知識共享。

優化表單開發流程與組件重用

問題點：
在公司的開發環境中，表單需求具有高度的重複性。每個新需求通常都會添加一個新的表單，即使這些表單大多數功能和結構相似。這不僅導致維護困難，而且在大型表單（如超過20或30個表格）的情況下，任何修改都會變得極為耗時。

解決方式：

1. 在開發過程中，我深入研究了 Ant Design 的底層架構，甚至查看了其源碼。
2. 這個過程讓我對 JavaScript 的 export 有了更深入的理解，包括如何將多個 export 包裝成一個物件或整個物件。
3. 基於這些知識，我開始整合公司內部常用的表單元件，並研究如何將它們打包為一個共用元件。

結果：
我成功地創建了一個高度可配置的共用表單元件。這個元件包含了所有預設的基本表格元素。開發者只需提供一個配置文件（config file），即可指定哪些表格應使用哪種元件（如 input、select 等），以及這些元件的狀態。這大大減少了重複開發相似表單的工作量，並提高了開發效率。

優化資料夾和檔案結構管理

問題點：
在當前的後台系統中，所有的 JavaScript 檔案都命名為 index.js，並存放在以元件名稱命名的資料夾下。這導致在開發工具的標籤頁中，大量的 index.js 檔案使得區分各個檔案變得困難。

解決方式：

1. 與主管進行討論後，我根據過去的經驗，開始採用更合理的資料夾和檔案命名規則。
2. 對於新開發的功能，我採用了這種新的結構，而對於舊有的頁面，我建議在未來有機會進行修改時，再進行結構調整。

結果：
新的資料夾和檔案結構不僅更加清晰，也獲得了團隊成員的正面反饋。這種改變大大減少了開發過程中用於識別和管理檔案的時間和精力。

這種優化提供了一個更加統一和可維護的代碼基礎，有助於提高整個開發團隊的效率和產出質量。

沒有善用生命週期

問題點：
在後台系統中，由於之前的開發者主要是後端工程師，對 React 的生命週期（Lifecycle）概念並不熟悉。結果是，幾乎沒使用到生命週期，僅有少部分元件使用了 componentDidMount（元件初始化時的生命週期方法），而幾乎沒有任何元件使用 componentDidUpdate（元件更新時的生命週期方法）。這導致整個應用主要依賴原生 JavaScript，而未充分利用 React 的特性。

解決方式：
我首先向前端和有興趣的後端工程師介紹了 React 生命週期的概念，並解釋了如何使用它可以簡化代碼和提高效率。
我自己也實作了幾個範例，以供他們參考和學習。

結果： 儘管大多數人仍然沿用原有的開發模式，但我認為這是因為生命週期是一個需要特定知識和理解的概念。只有在特定情況下（例如動態 select 元件）才會考慮使用生命週期方法。

附註： 什麼是 React 生命週期？這是一個在 React 元件中非常重要的概念，它描述了元件從創建到銷毀的各個階段。更多詳細資訊，可以參考我之前寫的筆記：前端框架 React：生命週期

這樣的優化嘗試雖然沒有立即產生廣泛的影響，但它為未來可能的改進鋪平了道路，並提供了一個更高效的開發模式作為參考。

結語

在這次的篇章中，寫到我第二份工作的狀況，讓我很意外，原來我做的事情比我記得的還多啊！主要是因為我當時工作較為忙碌，所以就沒有在關於這份工作的筆記或是文章，便只憑藉著我的履歷去想起之前做過的事情。

這次的寫作過程也讓我重新思考了我的專業成長路徑。我發現，即使在忙碌的工作中，我還是有機會去優化流程，提升效率。這些改進不僅讓我的工作變得更輕鬆，也讓我對自己的專業能力有了更多的自信。

在寫的時候，我不禁想到，是否應該聯繫一下之前的同事，看看他們是否還在使用我當時引入的工具或方法。不過，考慮到這都是將近兩年前的事了，也許那些同事已經換了新工作，或者公司也有了新的流程。

總之，這次的鐵人賽不僅是一次回顧，也是一次自我反思和成長的機會。我期待在未來能持續這樣的學習和進步，不僅在技術層面，也在人際互動和自我管理方面。

這次的經驗也讓我更加確信，持續學習和反思是任何專業成長不可或缺的部分。我也希望透過這次的分享，能夠激勵到其他正在路上的工程師，讓大家一同成長。

在下一篇文章中，我將分享我被賦予一個全新的專案規劃機會的事情，希望你會喜歡這篇文章。

文章就說到這，有什麼想法或問題，歡迎隨時找我聊聊！

這篇文章也會同步發在 medium 上，如果有興趣歡迎追蹤我。

medium: https://medium.com/@hugh-program-learning-diary-js
email: u88803494@gmail.com